IBIS Macromodel Task Group Meeting date: 23 June 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC * David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki * Nicholas Tzou Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad: Walter is not here today. - Topic was to be GND cleanup in the IBIS spec. - Walter did send us a draft last Friday. - We could discuss, but if that doesn't go far we may have a short meeting. - Bob: I don't recall receiving the draft. Was it private? - Arpad: [Reviewing email distribution list] - It was sent to Mike LaBonte, Radek, Fangyi, Michael Mirmak, Todd and me. - I guess it was semi-private. - I would have forwarded it to the group if I had noticed. - Arpad: Does anyone have any discussion topics that aren't on the agenda? - Michael M: If we run out of topics, I'd like to suggest we go through the existing list of open BIRDs from the Open Forum list. - See how they're being disposed of. - Some are being handled through the interconnect improvements. - If any are pending that should be dealt with here, perhaps we should add them to your list. - Arpad: That's a good suggestion. We could do that. - Any other Opens for today's meeting? [none] -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None. - Curtis: We did not record any ARs last week. - One thing to mention. - Walter replied with two minor corrections to make sure the spirit of his comments were properly reflected in the minutes. - I sent an update with Walter's corrections to Mike LaBonte. - The original minutes and the modified version are both posted. - Arpad: - This reminds me of a conversation Curtis and I had after the last meeting. - Curtis asked me if I wanted to review minutes before he posted them. - I replied that I had read all the minutes he had taken previously, and I trust his notes because they have been really good. - I didn't think it was necessary for me to approve every set of minutes. - But that raised the question, should we do it more formally and have the minutes approved here in this meeting, like we do in the Open Forum? - Michael M., would you have a suggestion on that? - Michael M.: It probably would be the right thing to do, not just for this meeting but for all of the meetings. - It would be good to have a formal flow for this. - I'd like to suggest we adopt an Open Forum like minutes flow. - Michael L.: I've seen some different practices for that. - Some meetings will literally read the last meeting's minutes verbatim. - Another practice is to have one attending member asked to review them. - Arpad: To have a designated person to do that approval? - Michael L: Advantage to that is one person to do it and it takes up less time. - Arpad: I'm worried about that approach. - If just one person reviews them then it might not serve the intended purposes of preventing accidental or deliberate misstatements. - Bob: I like the idea of putting them out for everybody. - Encourage people to review them and submit corrections via email. - Michael L: Another approach is what we do in Open Forum meetings. - Topic is on the agenda. - Ask if anyone has comments or corrections on the previous meeting's minutes. - Then a motion to approve. - Arpad: I agree with that. Just like we do it in the Open Forum. - Michael L: Gives everyone an opportunity, but doesn't take much time. - Arpad: If no one reads the minutes then it's our own problem ;-) - I don't think we will run into malicious intent with any of our groups. - Arpad: I would like to formalize this. - Do we have a motion to instate this extra step in our meetings? - Michael M.: I so move. - Michael L.: I so second. - Arpad: Anyone opposed to reviewing minutes each meeting? [none] ------------- New Discussion: - Arpad: Walter sent out a draft GND document. - I didn't notice that it was not sent to everyone. - Most people here today did not see it yet. - I suggest we postpone this topic. - Bob: I suggest we postpone it until next meeting, though I won't be here. - I don't know what has changed. - I reviewed draft 2, and there were substantial changes like changing everything to A_puref and A_gcref. - Arpad: [sharing Walter's email] - Says it documents what needs to be looked at. - Many of the changes can go away if we say GND is not simulator reference node, nor is it node zero, but it's a local rail such as the model terminal connected to the pull down or ground rail... - Unfortunately, much of the buffer graphics is related to derivation techniques, not how buffers are used. - Further complicated by using a model where rail voltages are fixed to the data derivation voltages as opposed to the rail voltages supplied during a power aware simulation. - Arpad: His email doesn't say too much about the actual changes. - Bob: That's a controversial item, because the derivation methods are based on fixed voltages. - Without seeing what he did, that statement itself is controversial. - Arpad: I agree that we should wait until Walter comes and we all review it. - Michael L., could you post it on the ATM site? - Michael L: Should I put that up dated today? - Arpad: Use the date the mail was sent out, since we didn't discuss it today. - Anything else on this topic? [none] - Arpad: Walter also mentioned Fangyi could perhaps talk about IR some more. - Fangyi: Not really, I think it's under control from the last meeting. - Arpad: Scott McMorrow read the minutes and would like to continue the topic. - He couldn't make it today, but is planning on joining next Tuesday. - Fangyi: I didn't see Scott's comments on the reflector. - Arpad: I'm not sure if it was private or public. - He definitely wants to continue the discussion. - It's an important topic to him. - Bob, any comments on this? Did you talk to him? - Bob: No, I don't. - We had some private emails. - It's best to make this a public topic next time. - Arpad: This topic is tabled for today. - Arpad: We could go with Michael M.'s suggestion and open up the IBIS website and review the list of open BIRDs. - Michael L: I'd compiled a spreadsheet with that info for the Open Forum. - We could use that. It might be a bit out of date. - Michael M: We now have two other BIRDS, 177 and 178. - BIRD 178.2 Specifying Buffer Directionality for AMI. - Bob: A potential new one is the interconnect proposal. - Michael M: That's not submitted yet, it will probably be at least a few weeks. - Michael L: That is definitely active in the interconnect meeting. - When I created this spreadsheet the goals were: - List the open BIRDs. - Figure out when they were last actively discussed in a group. - Just a few notes. - BIRD 128, was tabled in ATM. - BIRD 145, rejection had been discussed at one point. - BIRD 161.1, seems like it was last discussed in interconnect in 2013. - Michael M: BIRD 161 was mine. - That was tabled because it would potentially be handled as part of the interconnect proposal. - Currently interconnect does not have language addressing it. - So it may come back to life. - We can't really untable it until the interconnect proposal is done. - Arpad: This is a good list. - Bob: Some of these we will probably reject. - That was Michael's question. What do we plan to do? - Michael M: Quite a few will be addressed by the interconnect BIRD. - Those will probably be rejected once interconnect is approved. - Others still floating around and may need to be addressed. - Bob: We can start at the top of the list and work down. - Arpad: BIRD 125.1, I wrote that a long time ago. - Surprised interconnect was discussing it. - Michael L: That's just mentioned because I searched through meeting minutes and found it. - Arpad: Yes, it might have been mentioned but no real discussion. - Michael M: Its content would be entirely subsumed in the interconnect BIRD? - Arpad: Yes, and the expectation is it would be rejected at that point. - Michael L: Should we wait for the interconnect BIRD? - Or entertain motions to reject? - Arpad: I think we should wait. - Not sure the new interconnect BIRD will be accepted. - Probability is low that it won't be accepted, but simpler to wait. - Arpad: Next one is BIRD 128. - Michael L: Probably necessary for cooptimization. - Bob: Probably will be approved in some form. - Arpad: Turns the input parameter into an i/o parameter. - Arpad: Next is BIRD 145.3. - That was Cadence's to allow [External Circuit] and legacy models to be cascaded so we could have interconnect models in the [External Circuit] driven by a legacy model behind them, which is currently not allowed. - I think the new interconnect model would probably make this irrelevant. - New interconnect BIRD allows us to call ISS subcircuits for interconnect. - This might get rejected if the new one passes. - Bob: The issue was it also makes the multi-lingual approach more complicated. - Piling on complications on top of complications. - However, if the interconnect proposal gets too complicated and has too much thrown in then I may switch hats and reject it and go with this one. - Arpad: Row 5 and Row 13 (Backchannel and Cooptimization). - These are either one and the same or close relatives. - Perhaps we should put them next to each other. - Bob: We can cross reference them. - Arpad: We might get some answers to this when Ambrish comes back with Cadence's response to Walter's presentation. - Arpad: Next, BIRD 157 - Parameterize [Driver Schedule]. - That was mine, based on the suggestion of Romi Mayder. - It is a useful BIRD for [Driver Schedule] if people are using it. - [Driver Schedule] currently has fixed delay values. - If you use the same buffer model at different frequencies, you have to rewrite all the delays in the hard coded format. - Would be nice to parameterize those for use with multiple frequencies. - But [Driver Schedule] is not a very hot item these days. - I haven't heard from Romi asking about it. - Michael L: You might want to contact him. - This might be a candidate for untabling. - Arpad: I should contact him. - This BIRD doesn't depend on any other BIRDs. - It gets rejected or approved on its own merits. - Bob: I'm probably not in favor of it. - There's still no way to bring in the clock, which may be a dependency. - Just fixed parameters. - I don't like bringing in the parameter method from multi-lingual. - Arpad: The main question now is how useful is [Driver Schedule] anyway. - [Driver Schedule] is basically a poor man's multi tap. - We can do a lot better now with AMI. - Arpad: Next, BIRD 158.3 - AMI Touchstone Analog Models - That was SiSoft's BIRD to provide a totally LTI analog buffer model using touchstone. - Scott might be interested in this given the recent discussions. - Bob: Yes, we might resurrect it. - Scott was opposed to it at first. - It is a fixed topology. That was the issue. - Arpad: I tend to have second thoughts about it, too. - Fixed topology, lacks flexibility. - Also goes against the grain of power integrity simulations since power and ground referencing is somewhat limited. - Might be useful for LTI requirements of AMI, but not for non-LTI analog model simulations. - Could stand on its own. - Arpad: Next, BIRD 161.1 - Supporting Incomplete and Buffer-only [Component] Descriptions. - Michael L: Is that in the interconnect proposal? - Michael M: It is not. - There is some handling of package and interconnect descriptions that are incomplete, and there are some implied interactions. - But this BIRD was intended to identify to the user and tool the intent of the model author to model the entire component or not. - This BIRD can wait until after the interconnect BIRD is complete. - Michael L: Does the interconnect group think this is in their domain? - Bob: I don't think it's in the interconnect domain. - My concern is that it has gotten complicated with subparameters. - All you want to convey is "yes" or "no" is the model a complete model? - Michael L: Like the touchstone analog buffer model BIRD, this one has a lot of models out there doing this already. - Bob: Yes, there's nothing that prevents you from creating a 1 Pin [Component]. - Michael L: Should this be in ATM? - Bob: I don't know when to bring it up. - If we want to add a new informational subparameter in 7.0, so be it. - But we support legacy IBIS without them, and there's nothing that prevents us from issuing partial models. - Arpad - This is vaguely related to recent discussion about the completeness of [Pin] and [Pin Number] lists between the package and the IBIS file. - This is also dealing with incomplete models. - Michael M: You're right. - The key difference is there we have an identified [Pin] list we can compare against the identified interconnect models. - That's separate from this informational keyword identifying to the user that the model you're working with is not intended to describe the entire [Component]. - Useful because there's no automated way to otherwise know you have gotten everything. - Bob: That's the valid point. - One application might be a large device and you only model one quadrant. - Michael M: I think this can stay tabled until interconnect is done. - Michael L: I'd just feel better if we kept a list of tabled topics like Arpad has on his agenda. - I don't see BIRD 161 on any of those lists. - Arpad: That tabled list wasn't purposeful on my part. - I just put the topics on the agenda, and then once tabled they move down to the tabled section. - I vaguely remember discussing BIRD 161 once in ATM. - I'm not sure why it didn't make it to my tabled list. - Michael M: Do we need to maintain an overall tabled list in this meeting? - I'm willing to make that motion. - Bob: I make a motion that we complete the tabled list with the BIRDs under consideration at this point. - Arpad: The motion is to complete my tabled BIRD list with all these BIRDs. - So we have a complete list? - Bob: Yes. - Arpad: Do we have a second? - Michael M: Second. - Arpad: Anyone opposed [none]. - Michael L., please send me the spreadsheet. - Arpad: BIRDs 163 and 164 (also 125) all competing with interconnect. - These are all addressing the same feature set. - I would expect one winner. Is that correct? - Bob: Interconnect would be the alternative approach. - The last three are multi-lingual approaches to the same problem. - Arpad: BIRDs 163 and 164 are using [External Circuit] for packaging or on die interconnect. - Bob: It has architectural implications. - [External Circuit] is that on die or outside the die? - Arpad: Yes, that's the debate. - Bob: Depends on interconnect whether we resurrect them or not. - Arpad: Expect these might be rejected then since interconnect is a superset. - Possibility of rejection is high. - Bob: Because we don't want to do the same thing two different ways. - Michael L: That comment applies to 125, 163, 164? - Bob/Arpad: Yes. - Arpad: Next, BIRD 165 - Parameter passing improvements. - I wrote this. - Currently parameter passing is done on the [External Circuit] or [External Model] keyword level. - But the [Circuit Call] is actually what instantiates the external circuits. - Having the parameter passing on the [External Circuit] level means every single instance gets the same value. - This BIRD is independent. - Its fate might depend on how much effort we want to put into continuing the use of these [External Model] and [External Circuit] keywords. - Arpad: Next, BIRD 166 - Redriver Flow. - Walter and Fangyi's solution. - Independent BIRD, will need to be discussed on its own. - Fangyi: Last time we decided to table it. - Walter and I will have more discussions. - Arpad: Yes, it can become active on its own at any time. - Arpad: I think we are done with this list. - Thanks for that suggested discussion. - Arpad: What was the intent of my "complete" list of tabled topics? - Just the ones that aren't being discussed elsewhere, for example in the interconnect meetings? - Arpad/Bob/Michael M./Michael L.: - [decided Arpad should list them all]. - Arpad: I'll keep a complete list in the agenda. - Any other questions before we hang up? - Next week I expect to discuss GND. - If Scott can make it we will also discuss the LTI modeling for AMI. - Thank you all for joining. AR: Mike LaBonte to post Walter's draft GND document. AR: Mike LaBonte to send his BIRD spreadsheet to Arpad. AR: Arpad to add review of minutes to the ATM agenda each week. AR: Arpad to add all BIRDs from the spreadsheet to the ATM agenda's tabled list. AR: Arpad to contact Romi Mayder regarding BIRD 157. ------------- Next meeting: 30 June 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives